With the Cyber Resilience Act’s first reporting deadline now weeks away, the European Commission has published the guidance organisations have been waiting for. Issued on 27 July 2026 as the Annex to Commission Decision C(2026) 5252 final, it sets out the Commission’s settled interpretation of four of the CRA’s most contested questions: scope and free and open-source software, the meaning of "substantial modification", the length and disclosure of support periods, and how the Regulation interacts with other EU legislation. The guidance is non-binding, only the Court of Justice can rule definitively, but it is the clearest signal yet of how "aware", "in scope" and "substantially modified" will be interpreted in practice. For risk and TPRM leaders, that clarity replaces ambiguity with testable criteria, and turns 11 September 2026 from an approaching date into an immediate action item.

Shreeji Doshi
Shreeji Doshi

Director, GRC | Cyber Risk

sdoshi@thomasmurray.com

Edward Starkie
Edward Starkie

Director, GRC | Cyber Risk

estarkie@thomasmurray.com

1. Purpose of the Guidance 

The Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), imposes horizontal cybersecurity requirements on "products with digital elements" placed on the EU market. Article 26 requires the European Commission to publish guidance to help economic operators, particularly SMEs, apply the Regulation. This Annex delivers that guidance, covering four mandated areas: the scope of the CRA (notably free and open-source software and remote data processing), the concept of "support periods", interplay with other EU legislation, and the meaning of "substantial modification". 

2. Status and Timeline to Finalisation 

The guidance was released on 27 July 2026, as the Annex to Commission Decision C(2026) 5252 final. This is a Commission Decision approving the content of the guidance for publication as a Communication, the substantive text is final, not a working draft. It follows an Expert Group consultation and a public consultation held between 3 March and 13 April 2026. The guidance is explicitly stated to be non-binding: only the Court of Justice of the EU can give an authoritative interpretation of the CRA. No further approval step is required before publication; organisations should treat the content as the Commission's settled interpretive position, subject to potential supplementary guidance (e.g. on interplay with the AI Act and DORA). 

3. Summary of the Guidance 

  • Scope & placing on market: Clarifies when standalone software, hardware/software combinations, source code, and complex systems are considered "placed on the market". Web apps and websites accessed only via a browser generally fall outside scope unless they support a product's function. 

  • Free and open-source software (FOSS): FOSS not monetised by its publisher is generally outside CRA scope. Charging for the software, monetising via data/other services, or conditioning access/updates on donations can trigger "placed on market" status. Introduces the new "open-source software steward" role with lighter, tailored obligations. 

  • Substantial modification: A change is "substantial" if it affects compliance with essential requirements or alters intended purpose, assessed on cybersecurity risk impact, not on the size of the change. Genuine security updates are generally not substantial modifications; spare parts identical to the original component are exempt. 

  • Support periods: Manufacturers must set a support period (minimum 5 years, or the expected use time if shorter) for vulnerability handling, and disclose the end date to purchasers. Iteratively released software needs a compliant support period declared at each substantial-version release. 

  • Important/critical products & core functionality: Classification (default / important class I or II / critical) is driven by a product's core functionality, not ancillary features, this determines whether self-assessment or third-party conformity assessment is required. 

  • Remote data processing (RDPS) & third-party dependencies: Clarifies when cloud/back-end processing is part of the product (RDPS) versus an external dependency or third-party component requiring due diligence under Article 13(5). 

  • Reporting & vulnerability handling: Clarifies when a manufacturer is "aware" of an actively exploited vulnerability or severe incident, triggering the 24-hour/72-hour/final-report notification chain to ENISA and CSIRTs. 

4. Impact on the September 2026 CRA Reporting Deadline 

The guidance does not move the reporting deadline, it confirms it. Under Article 69(3) and 71(2), the obligation to report actively exploited vulnerabilities and severe incidents to ENISA/CSIRTs (Article 14) applies from 11 September 2026, ahead of the full CRA application date of 11 December 2027, and applies even to products already on the market. The guidance sharpens the practical trigger for this deadline by defining when a manufacturer is deemed to "become aware" of a reportable event (reasonable degree of certainty following prompt initial assessment) and by confirming the three-stage notification clock: an early warning within 24 hours, an expanded notification within 72 hours, and a full report within 14 days (vulnerabilities) or one month (incidents) of remediation. Organisations placing or sourcing in-scope products should confirm, well before 11 September 2026, that reporting workflows, CSIRT contact points, and "awareness" triage criteria are operational. 

4.1 How a CRA Report Reaches the EU Vulnerability Database (EUVD) 

The guidance's "awareness" trigger sets the clock running, but it is worth understanding where the notification goes next, since this is what ultimately makes an exploited vulnerability visible to the wider market: 

  • Manufacturer → Single Reporting Platform (SRP): the manufacturer submits the 24-hour/72-hour/final report once, via the CRA Single Reporting Platform, which ENISA established and operates under Article 16. 

  • SRP → CSIRT coordinator + ENISA: the SRP routes the notification to the CSIRT designated as coordinator in the manufacturer's member state of main establishment and, unless particularly exceptional circumstances justify a delay, makes it available to ENISA at the same time. 

  • CSIRT → EU CSIRTs network: the receiving CSIRT shares the notification without delay with every other CSIRT in whose territory the product has been made available, using the EU CSIRTs network for which ENISA acts as secretariat. 

  • CSIRT/ENISA → EUVD: separately, ENISA maintains the European Vulnerability Database (EUVD), established under Article 12(2) of NIS2, which aggregates vulnerability information from CSIRT advisories, vendor advisories, CVE data and other open sources, and supports the CSAF automation standard. 

A CRA notification is not automatically published in the EUVD in real time, the CRA recitals direct ENISA to develop complementarities between the SRP/CSIRT process and the EUVD, rather than treating them as a single feed. In practice, once a vulnerability has been triaged and, where appropriate, a coordinated advisory issued, it can surface in the EUVD's "exploited" or "EU-coordinated" views with CSIRT- or ENISA-sourced enrichment. For TPRM, this has two practical implications: (i) a vendor's CRA-reported, actively exploited vulnerability should, once processed, become visible through CSIRT advisories and/or the EUVD rather than remaining solely vendor-confidential; and (ii) the EUVD is a legitimate, independent source that TPRM and vulnerability-management teams can query to cross-check a vendor's own disclosures and patch timelines.

5. Positive Implications for TPRM, and What TPRM Leaders Should Do 

The guidance is a net positive for TPRM. It replaces ambiguity with testable criteria. Core functionality, RDPS vs. component, FOSS steward vs. manufacturer, substantial modification, these are now defined. TPRM teams can build them directly into due diligence, contracts, and vendor tiering. No more relying on vendor self-declaration alone. Risk teams also gain a defensible basis to challenge vendors who understate their CRA obligations. 

Recommendations for evaluating CRA in-scope providers: 

  • Confirm scope. Verify the product is genuinely a "product with digital elements". A website or an out-of-scope back-end is not. Request the vendor's own scoping rationale. 

  • Verify classification. Request the vendor's core-functionality classification, default, important I/II, or critical. Confirm the matching conformity route: self-assessment, notified-body involvement, CE marking, EU declaration of conformity. 

  • Align support periods. Obtain the declared support period and end-of-support date. Compare it to your own expected use time. Flag any mismatch as a contract or exit-planning risk. 

  • Test reporting readiness. From 11 September 2026, confirm the vendor can detect, assess, and report actively exploited vulnerabilities within the CRA clock. Require timely pass-through notification to you in the contract. 

  • Scrutinise cloud dependencies. For vendors on third-party IaaS/PaaS/SaaS or RDPS, request their own due-diligence evidence — NIS2/DORA compliance, ISO/IEC 27001 or 27017. Do not accept the cloud provider's certification as a substitute. 

  • Check FOSS exposure. Confirm vendors exercise due diligence on embedded open-source components. Confirm upstream reporting and patch-sharing practices. Treat unmaintained or steward-only dependencies as a heightened risk. 

  • Govern change. Add a substantial-modification trigger to vendor governance. Re-assess major releases for compliance and support-period impact, not just functionality. 

  • Update contracts. Refresh questionnaires, SLAs, and right-to-audit clauses. Require CRA attestations and Article 14-aligned notification duties. Track vendor readiness against 11 Sept 2026, 11 Dec 2027, and 11 June 2028. 

Source: European Commission, Annex to C(2026) 5252 final, 27 July 2026 — Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act). This briefing is a summary for internal risk discussion and does not replace legal advice.
Cyber Risk

Threat Intelligence Reports

Our custom cyber threat intelligence reporting delivers strategic, operational, and tactical insights tailored to your organisation's unique needs. We help organisations understand and address specific threat landscapes across industries and geographies through detailed, actionable reports, enabling informed decisions to safeguard operations at all levels.

Learn More